The new generation mobile devices, such as smart phones, provide more and more enhanced computational functionalities via open network connections. Such mobile devices are e.g. capable of receiving e-mail, share software with one another through short-range connections, downloading and executing software from the Internet, making automated calls and act under remote control. Hence, similar to a personal computer, mobile devices and in particular the software components involved in the setting up of a connection between the mobile device to the network, are vulnerable to attacks of malicious code (malware). Typically malware attempts to make misuse of mobile device or to simply disrupt legitimate use of the mobile device.
One example of misuse includes a malware initiating the calling of premium rate telephone numbers or the sending of premium rate SMS messages without the user of the mobile device noticing this. Such a misuse can lead to unpleasant billing surprises for the user.
Another example of misuse includes making calls on the victim's expenses, e.g. by stealing the authentication data of the victim's UMTS Subscriber Identity Module (USIM) using malware on the victim's device and subsequently impersonating the victim's device.
Such a misuse is possible via a specific type of a man-in-the-middle attack, sometimes referred to as a relay attack. In a relay attack, the malware installed on the victim's device sets up a communication link to the attacker's device. The attacker can successfully impersonate himself as the victim towards the mobile network by relaying the received authentication challenge towards the malware, which, in turn, requests the victim's Universal Subscriber Identity Module (USIM) to calculate the corresponding response. Subsequently the malware sends the response to the attacker's device, which forwards it towards the network. This results in the network granting access to the attacker after which the attacker can use any service on the victim's expenses.
Such an attack is schematically presented for UMTS authentication and key agreement (AKA) in FIG. 1. As shown, in step one (different steps are illustrated in FIG. 1 with arrows having corresponding numbers), an attacker determines, via the data link that the malware has set up with the victim's mobile device or personal computer, the victim's International Mobile Subscriber Identity (IMSI). In step two, the attacker provides the IMSI to a network from which it desires to obtain a particular service (such a network is represented in FIG. 1 as a “Base Station”). In step three, the attacker receives a random value RAND from the network that it must respond to by sending a response RESP in order to obtain access to the network. The attacker also receives from the network a value AUTN, which is an authentication token sent by the UMTS network to the subscriber's USIM. In steps four and five, using the data link that the malware has set up with the victim's mobile device or PC, the attacker relays RAND and AUTN values to the USIM of the victim. The USIM then calculates the corresponding response RESP. In step six, the malware on the victim's device transmits the response RESP to the attacker who, in step 7, forwards this response to the network. After successful authentication, the network considers the attacker as the rightful subscriber allowing the attacker to set up calls or obtain other services that subsequently will be charged to the (impersonated) rightful subscriber.
Currently, the UMTS network may make use of a network authentication code (AUTN in FIG. 1) for the purpose of preventing a so called “false base station attack”, which is an attack where a base station is introduced that does not belong to the network, but successfully masquerades as one. While using an authentication code successfully counters several attacks of this type, it does not prevent an attack as described above because the attacker can easily send the authentication code to the rightful subscriber through a data link that is set up by malware on the subscriber's mobile device.
As the foregoing illustrates, what is needed in the art is a technique for establishing a secure communication channel between at least the USIM and other hardware components of the mobile device.
Known prior art solutions such as disclosed in US 2006/0288209 suffer from the disadvantage that the secure communication between two components of a device is limited to hardware components wherein the security key is loaded and fixed into the components prior to the actual use of the components. This has a disadvantage that the hardware components which have been provisioned with the same security key need to be distributed together. In the case of US2006/0288209 this is easily done because it is meant for secure interprocessor communication on portable electronic devices with two processors. Hence, the components with the same security key are inherently together. However in a situation where the hardware components are not distributed together, provisioning and maintaining the relation between the components becomes very complex. For instance when the two hardware components are a mobile phone and a USIM. In this situation the mobile phone and the USIM are manufactured, distributed and sold by different organizations and there is a need to be able to create a security association between these two components regardless. The present invention provides a solution for this problem.
The prior art solutions as disclosed in US 2009/0257590 and EP1662697 rely on a technique wherein the secure communication channel between different components of a digital system are exchanged in an encrypted format. These approaches have as a disadvantage that the key pairs which are generated can also be generated by malware. Since the prior art as disclosed in US 2009/0257590 and EP1662697 either don't provide authentication of the different components or rely on pre-provisioned data the same problem arises as disclosed in the prior art of US2006/0288209. This means that any entity can generate the keypairs and push a public key to another hardware component in order to set up a secure connection, including malware, and the receiving hardware component can't distinguish this. Secondly asymmetric key operations are more complex and require more power. On mobile devices this effect is undesirable.